home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 081 / opushelp.arc / OPUSHELP.DOC
Encoding:
Text File  |  1987-07-28  |  6.8 KB  |  198 lines
  1.                     Opus 1.0 Simple Help Documentation
  2.                                     by
  3.                         Bob Hartman (node 132/101)
  4.                                      
  5. In the  past 2  1/2 weeks I have received a lot of phone calls and messages
  6. about problems  that people  have had  with oMMM and/or Opus 1.0 (or 1.01),
  7. and I decided that I would finally create a document to help matters just a
  8. bit.   Below you  will find some problems, then the solutions for them.  If
  9. you have something that isn't answered here, please send a message to David
  10. Finster at OpusInfo (node 124/111 primary address).
  11.  
  12. Problem #1:
  13.  
  14.      I am not sending out ARCmailed packets like I am supposed to.
  15.  
  16. Solution:
  17.  
  18.      You need  to have one of the following statements in your oMMM control
  19.      file:   ArcTo, Hold,  Crash.  All three do ARCmailing, and the keyword
  20.      used determines  whether it  will be  a normal  ARCmail file,  a  held
  21.      ARCmail file, or a Crash ARCmail file.
  22.  
  23. Problem #2:
  24.  
  25.      I am trying to poll a node, but I call his network host instead.
  26.  
  27. Solution:
  28.  
  29.      You are  probably using  something  like  the  following  sequence  of
  30.      statements:
  31.  
  32.           POLL x/y
  33.           ...
  34.           ROUTE
  35.  
  36.      What you  are doing  is creating a .OUT file (via the POLL statement),
  37.      but then  you are  host-routing the  .OUT file  when you use the ROUTE
  38.      statement.   The trick  is to  make the  .OUT file into something else
  39.      that will not be ROUTE'd.  Try the following:
  40.  
  41.           POLL x/y
  42.           DIRECT x/y
  43.           ...
  44.           ROUTE
  45.  
  46.      This way  the .OUT file is converted into a .DUT file before the ROUTE
  47.      statement gets  executed.   ROUTE (like most other oMMM control verbs)
  48.      only works on .OUT type files.
  49.  
  50. Problem #3:
  51.  
  52.      My nodes that I hold for are having their messages lost.
  53.  
  54. Solution:
  55.  
  56.      This can happen a couple of ways, but the most common that I have seen
  57.      is the case where there is a line in the oMMM control file like:
  58.  
  59.           HOLD x/y a/b c/d ...
  60.  
  61.      If you  read the  documentation  carefully  you  will  see  that  this
  62.      statement causes  mail for  a/b, c/d  and the  rest to be placed in an
  63.      archive that  is held for node x/y.  What you really want is something
  64.      like:
  65.  
  66.           NormHold x/y a/b c/d ...
  67.      The above  statement is  used if  you  do  not  want  to  ARCmail  the
  68.      messages, if you do want to ARCmail them, then use:
  69.  
  70.           OneHold x/y a/b c/d ...
  71.  
  72. Problem #4:
  73.  
  74.      My forced  Z-event for  sending only  crash mail  does not  seem to be
  75.      working properly.
  76.  
  77. Solution:
  78.  
  79.      This is  a particulary  nasty problem.   As  far as  I can tell (and I
  80.      might be wrong on this, but it seems to hold as far as I can test it),
  81.      a FORCED event will happen EXACTLY ONCE.  So, lets say that you have a
  82.      forced Z-event that runs from 1:00-3:00.  At 1:00 it runs and converts
  83.      you to  a crash  only system.   Now  at 2:00 you exit the system to do
  84.      some maintenance  and start  it up again.  Well, your forced event has
  85.      already taken  place, and  won't be  done again.   You end up with the
  86.      default Z  event from  your control  file.   The  solution  is  rather
  87.      simple:
  88.  
  89.           Z-events should NEVER BE FORCED events.
  90.  
  91.      This way  they simply  get noticed  whenever Opus  is checking on what
  92.      event it  is executing,  and the change will take place.  Like I said,
  93.      this one is particulary nasty since it sort of goes against the normal
  94.      train of thought.
  95.  
  96. Problem #5:
  97.  
  98.      My system  does not  seem to unpack any mail packets that it receives.
  99.      I see  the .PKT  files in  the inbound  file area,  but  then  nothing
  100.      happens to them.  I use FastToss (or ConfMail) to toss the rest of the
  101.      echomail, but still the .PKT files remain.
  102.  
  103. Solution:
  104.  
  105.      Unfortunately, it  appears that  Opus will  only unpack  mail  if  the
  106.      switch to  Extract ARCmail  or the switch to Toss Echomail is enabled.
  107.      If you  don't use  FastToss or  ConfMail, then the solution is just to
  108.      enable one of those options.  If you do use FastToss or ConfMail, then
  109.      the following batch file workaround should do the trick:
  110.  
  111.           COPY inbound_dir\*.PKT opus_root_dir
  112.           DEL  inbound_dir\*.PKT
  113.           FastToss -N -A   or   ConfMail Import -N -A
  114.  
  115.      This will move those .PKT files to a location where either FastToss or
  116.      ConfMail will be able to extract them.
  117.  
  118. Problem #6:
  119.  
  120.      My events are executing at the wrong times.
  121.  
  122. Solution:
  123.  
  124.      This is  caused by an improper setting of the TZ environment variable.
  125.      Set your  system clock  to the  same time as the clock on the wall and
  126.      experiment with  the TZ  environment variable.   Currently  we are  in
  127.      Daylight Savings Time, and TZ=EDT4 works here on the East coast.
  128.  
  129. Problem #7:
  130.  
  131.      I can't exit from the C)hange menu.
  132. Solution:
  133.  
  134.      This is caused by having the Opus 0.0 privilege files in place instead
  135.      of the  Opus 1.0  privilege files.   You  will  need  to  replace  the
  136.      CHGPRIV.BBS file.   Another  method that  I have heard will work is to
  137.      get into  the !)Sysop  menu and  alter the  privileges for the C)hange
  138.      menu.   When Opus  re-writes the file it is in the proper format again
  139.      (supposedly - you would have to try this yourself to verify it).
  140.  
  141. Problem #8:
  142.  
  143.      I can't get Wxmodem or CKermit to work with Opus 1.0.
  144.  
  145. Solution:
  146.  
  147.      You are  quite correct.  Wxmodem and CKermit were flakey at best under
  148.      Opus 0.0,  and officially  are not  even supported there.  There is no
  149.      new Wxmodem  for Opus  1.0, but  there is  a new  Kermit in  the  file
  150.      OKER_100.ARC.   It uses the new external program interface provided by
  151.      Opus and described in the file OREF_EXT.ARC available from 150/1.
  152.  
  153. Problem #9:
  154.  
  155.      I can't  X)port messages  from the  Matrix area,  but I can from other
  156.      areas.
  157.  
  158. Solution:
  159.  
  160.      Use the !)Sysop menu to change privileges in the M)atrix menu.
  161.  
  162. Problem #10 (a late addition):
  163.  
  164.      My HOLD  statement doesn't  seem to  be having any affect.  I have the
  165.      following in my oMMM control file:
  166.  
  167.           ArcTo x/y
  168.           Hold x/y
  169.  
  170. Solution:
  171.  
  172.      You are  running into the problem of dealing with oMMM as a sequential
  173.      processor.   Both ArcTo,  and Hold  create ARCmail for the given node.
  174.      Since the ArcTo statement is executed first, there is nothing left for
  175.      the Hold statement to work on.  There are two possible ways around the
  176.      problem:
  177.  
  178.           Hold x/y
  179.  
  180.      Which does  what you want the above two to do anyway.  Or, if you need
  181.      to do some more processing between the statements, perhaps:
  182.  
  183.           ArcTo x/y
  184.           ...
  185.           NormHold x/y
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.